NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/638

Internet Message Format | 1996-08-05 | 4.4 KB

Path: mail2news.demon.co.uk!sisyphus.demon.co.uk
From: [e-mail]
Newsgroups: comp.sys.amiga.programmer
Subject: Re: PPC compilers
Date: Tue, 9 Jan 96 22:57:34 +0000 (GMT)
Organization: to be supplied
Message-ID: <[e-mail]>
References: <[e-mail]> <4ck47h$[e-mail]> <[e-mail]> <4cokkg$[e-mail]> <[e-mail]> <4cqrti$[e-mail]>
X-NNTP-Posting-Host: sisyphus.demon.co.uk
In-reply-to: [e-mail]'s message of 8 Jan 1996 10:33:22 GMT
X-Attribution: DaveS
Content-Length: 3768
X-Lines: 99
X-Mail2News-Path: relay-4.mail.demon.net!post.demon.co.uk!sisyphus.demon.co.uk

>>>>> "SS" == Stephan Schaem <[e-mail]> writes:

  SS> [e-mail] wrote:

  SS> I cant see how people can write code without knowing what data
  SS> or type they manipulate...

  >> Real-world programmers do it all the time.  If you ever want to

  SS> So you do math operation without knowing that your destination need
  SS> to be a float or a 2 byte int?

  >> Yes.  This is a trivial example of polymorphism.

  SS>  polymorphism?

  SS>  int a,b,c;

  SS>  ...  a = b /c; a *= result; ...  struct.float = a;

  SS>  I dunno , I just find it puzzling to declar variable without giving
  SS> a care of what its usage will be. You programing practice is VERY
  SS> unwise...

If I want to store a value of type clock_t, I declare a value of
type clock_t - knowing that it could be signed or unsigned int or
long, or float or double.

 I guess I really have to spoon feed you a real life example.

    clock_t start_time, end_time;
    double time_used;
    ...
    start_time = clock ();
    ...
    end_time = clock ();
    time_used = ((double) (end_time - start_time)) / CLOCKS_PER_SEC;
    ...
    printf ("Time used was %.3f seconds/n", time_used);

is hardware-independent ANSI C.  Don't worry about the few
floating-point operations: anyone who is worried about performance
will have hardware which can execute floating-point ops
asynchronously.  If the C compiler does its job properly and
generates the instructions in the best order, the floating-point
ops will be executed in parallel and the total execution time may
even be _less_ than the time which would have been needed if
fixed-point had been used.

  SS>  You said yourself after peeking at the .h that clock_t was
  SS>  a ulong.

I didn't peek the .h , I read the docs.  And my code doesn't
depend on clock_t being unsigned long.

  SS> ...

  SS> about loop counter size... should I use ulong and forget about it, or
  SS> use ushort to be sure of optimal speed on my target CPU and remember
  SS> my declaration type in case I want to use it for a loop count bigger
  SS> then 65535?. (this result in a sub/bcc vs dbcc encoding on 680x0... )

  >> target CPU?  How quaint ...

  SS>  But target CPU is something that come up often in the real world of
  SS> programming... oh, forgot you think you are part of it.  C compiler

If your product is a large, expensive program with a small niche
market, and your various potential customers use Amiga, SUN,
RS6000 or HP, you can't afford to target your code on a single
processor type.  You may have to write some parts of your program
in assembly code, either for performance or because some functions
can't be performed in C, but you'll be reluctant to do so because
the assembly code will have to be written and tested four times.

  SS> ...

  >> ...
  >> loop; it couldn't use dbcc anyway.  You don't get optimal speed by
  >> optimizing the instructions, but by optimizing the algorithm.

  SS> ...

  SS>  The way you get optimal speed is optimizing the optimal algorithim.
  SS> If you stop at the algorithm you loose... Optimizing at this stage
  SS> will give an exponential result on the work you done on the
  SS> algorithm.  And usually this stage is done in assembler.

Getting the algorithm right can improve performance by orders of
magnitude (i.e. not thinking about the algorithm can degrade
performance by a factor of ten or more).  Writing everything in
assembler might save 20% over writing everything in C and using a
good compiler.  Writing the bulk of your code in C and a small
proportion (less than 5%) in assembler is usually a good compromise.

--
        [e-mail]        (Staffordshire, England)

 ... details are more implementation-dependant than defined.